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SECURE STORAGE OF PRIVATE KEYS 



BACKGROUND OF THE INVENTION 
1 Field of the Invention 

The present invention relates generally to cryptographic systems, and more 
particularly, to securing private keys in a public key cryptographic system. 

2. Description of Related Art 

The increasing accessibility of public networks, such as the Internet, allow a 
wide variety of data to be quickly and cost effectively accessed from virtually 
anywhere. The Internet, for example, allows users to access databases such as 
web page servers from any computer connected to the Internet. 

One disadvantage with using a public network or an insecure private network 
to access information is the possibility that sensitive or private information may be 
accessed, modified, or intercepted by an unauthorized party. These problems can 
be mitigated, however, by using public key cryptographic systems. In these 
systems, an authorized person can digitally sign messages to verify their source and 
information can be encrypted before it is transmitted over the insecure network. The 
receiver of the signed message will be assured that the message originated from the 
authorized person. The encrypted information, even if unlawfully intercepted, is not 
intelligible. In this manner, an insecure network may act functionally like a private 
and secure network. 

The basic components of a public key cryptographic system include a 
cryptographic algorithm and two numerical codes called keys, one of which is 
referred to as the public key and the other the private key. To encrypt information, a 
user inputs a public key to the cryptographic algorithm along with the information to 
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be encrypted. The resultant information, encrypted with the public key, can only be 
decrypted with the corresponding private key. For example, if a first user encrypts a 
message with the public key, only the holder of the private key can recover the 
original message. Even the first user, absent the private key, cannot decrypt the 
message. 

Parties wishing to securely communicate with one another over an insecure 
network using a public key cryptographic system begin by exchanging their public 
keys. The sending party then encrypts its information using the second party's 
public key. The second party decrypts the received information using its private key. 
Similarly, when digitally signing a document using public key cryptographic systems, 
the signing party signs the document using its private key. Correctly decrypting the 
signature with the signing party's public key verifies the identity of the signing party. 

For a public key cryptographic system to be reliable, the communicating 
parties must keep their respective private keys secure. A user's private key is 
typically stored at the user's computer. To guard against someone stealing the 
private key, either by unauthorized physical or logical (i.e., programmatical) access 
to the user's computer, conventional public key encryption systems encrypt the 
user's private key using a symmetric encryption algorithm that uses a single key 
based on a password entered by the user. The encrypted version of the private key 
is only secure, however, if the user uses a "strong" password. Weak passwords- 
passwords that are short or based on real words — are vulnerable to brute force 
cracking algorithms that discover a private key by decrypting the stolen but 
encrypted version of the private key by methodically trying a large number of 
possible passwords. 
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Strong passwords are passwords that are long enough so that a brute force 
attack is not likely to be able to guess the correct password. Strong passwords, 
although desirable from a security standpoint, are not particularly user friendly. 
Users do not like to type in long phrases every time they begin a secure session. 
Additionally, strong passwords can be difficult to remember. 

Accordingly, there is a need in the art to improve the user friendliness of 
passwords used to protect a private key without compromising the security offered 
by strong passwords. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute a part of 
this Specification, illustrate an embodiment of the invention and, together with the 
description, explain the objects, advantages, and principles of the invention. In the 
drawings: 

Fig. 1 a diagram illustrating an exemplary computer network on which concepts 
consistent with the present invention may be implemented; 

Fig. 2 is a flow chart illustrating a method for registering a private key with a 
key server according to methods consistent with the present invention; 

Fig. 3 is a flow chart illustrating a method for accessing a user's private key 
that has been registered with a key server; 

Fig. 4 is a flow chart illustrating a second method for registering a private key 
with a key server according to methods consistent with the present invention; and 

Fig. 5 is a flow chart illustrating a method for accessing a user's private key. 
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DETAILED DESCRIPTION 

The following detailed description refers to the accompanying drawings that 
illustrate the embodiments of the present invention. Other embodiments are possible 
and modifications may be made to the embodiments without departing from the spirit 
and scope of the invention. Therefore, the following detailed description is not meant to 
limit the invention. Rather the scope of the invention is defined by the appended 
claims. 

As described herein, a key protection server is connected via a network to a 
user's computer. The key protection server and the user's computer each store a 
portion of the information needed to compute the user's private cryptographic key. The 
user additionally protects his private key with a password, which may be a weak 
password. A security breach at either the key protection server or the user's computer 
does not jeopardize the user's private key, even to standard brute force attacks. 

Fig. 1 is a diagram illustrating an exemplary computer network in which 
concepts consistent with the present invention may be implemented. The computer 
network includes multiple client computers 108 coupled to network 105, which may be, 
for example, the Internet. Client computers 1 08 each typically include a processor 110 
operatively coupled to computer memory 1 1 1 and a display 1 12. Processor 110 
executes program instructions stored in computer memory 111, such as 
cryptographic program 130. 

Users 120 may use any of client computers 108 to communicate with key 
server 101. In general, key server 101 assists users 120 in managing their private 
keys. 
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Client cryptographic program 130, which is described in more detail below, 
encrypts, decrypts, and/or digitally signs information being transmitted to and 
received from other users 120. Additionally, client cryptographic program 130 
communicates with key server 101 to securely store the private keys of users 120. 
Although shown as a single program, cryptographic program 130 may be a multitude 
of cryptographic programs, each providing part of the functionality of cryptographic 
program 130. 

As with client computers 108, key server 101 includes at least one processor 
1 13 and a computer memory 1 14. Memory 114 includes remote server 
cryptographic program 150, which interfaces with client computer cryptographic 
programs 130. 

Remote server cryptographic program 150, as will be described in more detail 
below, stores a portion of the information needed to compute a user's private key 
along with additional user identifying information. Cryptographic program 130 and 
remote server cryptographic program 150 operate together to securely compute the 
user's private key in the user's computer memory 111. 

Client computers 108 and key server 101 may either accept program 
instructions from a computer storage device (e.g., optical or magnetic disk) or from 
network 105. BIOS code (i.e., computer instructions) causing the system to 
implement the disclosed techniques may be programmed into a non-volatile portion 
of computer memories 1 1 1 and 1 14. The BIOS may be programmed when the 
system is manufactured or may be later delivered via a computer readable medium. 

Client processors 1 10 and key server processor 1 13 can be any of a number 
of well known computer processors, such as processors from Intel Corporation, of 
Santa Clara, California. More generally, client computers 108 may be any type of 
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computing platform connected to a network and that interact with application 
programs, such as a personal digital assistant or a "smart" cellular telephone or 
pager. 

Before a client computer can begin to securely communicate using public key 
encryption with another party, it first generates a public/private key pair. As mentioned, 
consistent with an aspect of the present invention, a portion of the information needed 
to compute the generated private key is stored at key server 101. Fig. 2 is a flow chart 
illustrating a method for registering the private key with the key server 101. 

The client computer begins by generating a public and a corresponding 
private key. (Act 201). The public key may be freely distributed. It is desirable to 
keep the private key, labeled as key K, as secure as possible. To this end, the user 
enters a password, PWD, to help protect the private key K. (Act 202). The 
password PWD may be of any length. In addition to generating the private key K, the 
client computer also generates a random number, K-PC, which is larger than the 
private key K. (Act 203). Generation of public/private key pairs and random 
numbers are well known in the art and will thus not be described further. 

The client computer 108 next computes a derivative of the private key K and 
the random number K-PC, called K-Ser, by exclusive ORing these two numbers. 
(Act 204). In this manner, K-Ser, related to the private key K, is created by client 
1 08. At this point, private key K may be deleted from memory 1 1 1 of client 1 08. 

Client computer 108 further enhances the security of K-PC and K-Ser by 
encrypting them using a symmetric encryption algorithm having a key based on a 
hash of the user's password PWD and login name. More particularly, client 
computer 108 computes a hash value, Hashl, based on the user's password PWD, 
user name, and a fixed random value (Saltl). (Act 205). User names (also called 
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login names), are commonly used in the computer art to identify users to a computer 
or network. With Hashl in hand, K-PC and K-Ser are "wrapped" using an encryption 
key based on Hashl . (Act 206). Wrapping a value refers to encrypting the value 
using a symmetric encryption algorithm. The encryption key used to wrap K-PC and 
K-Ser may be Hashl itself, or a variation of Hashl designed to yield an appropriate 
length encryption key. K-PC and K-Ser can only be unwrapped with the encryption 
key used to wrap them. 

A second hash value, Hash2, is generated by client computer 108. (Act 207). 
As with Hashl, Hash2 is based on the user's password PWD, user name, and a 
second fixed random value (Salt2). Saltl and Salt2 are fixed random numbers that, 
once initially generated, are stored at client computer 108. 

Hashl and Hash2 may be implement by different mathematical hashing 
functions or the same hashing function. The PKCS #5 encryption suite, available 
from RSA, Inc., of Bedford, Massachusetts, includes suitable cryptographically 
secure hashing algorithms. In general, hashing algorithms take arbitrary strings as 
input, and produce an output of fixed size that is dependent on the input. Ideally, it 
should never be possible to derive the input data given the hash algorithm's output. 
For a hashing algorithm to be cryptographically secure, it must be very difficult to find 
two input strings that produce the same output hash value, or to find an input string 
that produces a given hash value. Because Saltl and Salt2 are different values, the 
values of Hashl and Hash2 will necessarily be, to a statistical certainty, different 
from one another. 

Having wrapped K-PC and K-Ser, client computer 108 registers with key 
server 1 01 by sending the user name, Hash2, and the wrapped version of K-Ser to 
key server 101 . (Act 208). These values are stored at the key server. 
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Communications between the client computer and the key server may be performed 
using the well known SSL (secure socket layer) protocol to further enhance security. 

Saltl , Salt2, and the wrapped version of K-PC are stored at the client 
computer 108. Other values generated by client 108, such as K-Ser, the wrapped 
version of K-Ser, and K, are not permanently stored at client 108. 

Fig. 3 is a flow chart illustrating a method for reconstructing the user's private 
key at client computer 108. The private key is required whenever the user would like 
to sign a message or read a document encrypted with the user's public key. 

Client computer 108 begins by obtaining the user name and password. (Act 
301). With these two values, and Saltl and Salt2, client computer 108 generates 
Hashl and Hash2. (Act 302). Hash2 and the user name are then sent to key server 
101. (Act 303). If the received value for the user name and Hash2 match the values 
stored by the key server during registration, key server 101 responds by transmitting 
the wrapped version of K-Ser back to the client computer. (Acts 304, 306). The 
client then unwraps K-Ser and K-PC based on Hashl , (Act 307), and calculates the 
private key K by performing a logical exclusive OR of the K-Ser and K-PC. In this 
manner, the private key K is obtained and may be used in subsequent public key 
cryptographic sessions. 

If Hash2 and the user name compared in Act 304 do not match the values 
stored by the key server during registration, key server 101 denies access to K-Ser. 
(Act 305). For each user name, the server will place an upper bound on the number 
of incorrect values of Hash2 that can be given before some preventative action is 
taken. For example, after 5 consecutive unsuccessful values, the server may not 
allow any more attempts for retrieval by that user name for a period of 1 hour and 
may send an email or other communication to the user notifying them of the 
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unsuccessful attempts. If the user had not actually made these attempts, the user 
would be advised to change their password. After 25 unsuccessful values, not 
necessarily consecutive, the server may lock the account until there is some out-of- 
band communication with the user. The numbers 5, 25, and 1 hour are examples, 
and may be different in actual use. 

Client computer 108, after obtaining the private key K, may delete the 
calculated intermediate values K-Ser, Hashl, and Hash2. 

A user may want to have the server store more than one key. For example, it 
is common practice to use a different private/public key pair for encryption than for 
digital signatures. A user may use the same value of Hash2 for multiple keys. In 
this case, the user could request the values of K-Ser for multiple keys with a single 
request to the server. 

A user may want to change their password PWD. To do this, the client 
program asks the user to enter their old password once, and their new password 
twice. The client program goes through the procedure described above to retrieve 
the user's private key using the old password. Then the client program goes through 
the procedure to store the private key using the new password. Server 101 could 
then delete the old stored values of Hash-2 and K-Ser. The server may want to have 
the user authenticate themselves, such as through a digital signature with the user's 
private key or through sending the old Hash-2 along with the new Hash-2, before the 
server deletes the old stored values. 

With the private key storage system and method described above, even if an 
unauthorized party breaks into one of client computers 108 and steals the wrapped 
version of K-PC, Saltl , and Salt2, it would still be very difficult to derive the private K. 
A brute force attack, for example, even if it was able to guess the correct password, 
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and thus unwrap K-PC, would have no way of knowing that it had the correct K-PC 
without having K-Ser. If an adversary tried to test for the correct password by 
computing and sending values of Hash2 to the server, the server will only allow a 
limited number of guesses. Similarly, if security at key server 1 01 is compromised 
and K-Ser accessed, a brute force attack would not be able to derive K without K- 
PC. 

An alternate embodiment consistent with the present invention for storing and 
retrieving a user's private key using a key server will now be described with 
reference to Figs. 4 and 5. 

Fig. 4 is a flow chart illustrating a second method for registering a private key. 

The client computer begins by generating a public and a corresponding 
private key. (Act 401). The public key may be freely distributed. It is desirable to 
keep the private key, labeled as key K, as secure as possible. To this end, the user 
enters a password, PWD, to help protect the private key K. (Act 402). The 
password PWD may be of any length. In addition to generating the private key K, the 
client computer also generates two fixed random values, Saltl and Salt2. Saltl and 
Salt2 should be relatively long, such as 160 bits in length. (Act 403). 

Client computer 1 08 further enhances the security of K by encrypting it using 
a symmetric encryption algorithm having a key based on a hash of the user's 
password PWD and login name. More particularly, client computer 108 computes a 
hash value, HasM , based on the user's password PWD, user name, and the fixed 
random value (Saltl). (Act 404). With Hashl in hand, K is wrapped using an 
encryption key based on Hashl . (Act 405). The encryption key used to wrap K may 
be Hashl itself, or a variation of Hashl designed to yield an appropriate length 
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encryption key. K can only be unwrapped with the encryption key used to wrap it. 

A second hash value, Hash2, is generated by client computer 108. (Act 406). 
As with Hashl, Hash2 is based on the user's password PWD, user name, and a 
second fixed random value (Salt2). Salt2 is a fixed random number that, once 
initially generated, is stored at client computer 108. 

Having wrapped K and computed Hash2, client computer 108 registers with 
key server 101 by sending the user name, Hash2, and Saltl to key server 101. (Act 
407). These values are stored at the key server. At this point, private key K and 
Saltl may be deleted from memory 1 1 1 of client 108. Communications between the 
client computer and the key server may be performed using the well known SSL 
(secure socket layer) protocol to further enhance security. 

Salt2, and the wrapped version of K are stored at the client computer 108. 
Other values generated by client 108, such as Saltl, and K, are not permanently 
stored at client 108. 

Fig. 5 is a flow chart illustrating a method for reconstructing the user's private 
key at client computer 108. The private key is required whenever the user would like 
to sign a message or read a document encrypted with the user's public key. 

Client computer 108 begins by obtaining the user name and password. (Act 

501) . With these two values, and Salt2, client computer 108 generates Hash2. (Act 

502) . Hash2 and the user name are then sent to key server 101 . (Act 503). If the 
received value for the user name and Hash2 match the values stored by the key 
server during registration, key server 101 responds by transmitting Saltl back to the 
client computer. (Acts 504, 506). The client then generates Hashl from the user 
name, the password PWD, and Saltl . (Act 507). The client then unwraps K based 
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on Hashl , (Act 508). In this manner, the private key K is obtained and may be used 
in subsequent Spublic key cryptographic sessions. 

If Hash2 and the user name compared in Act 304 do not match the values 
stored by the key server during registration, key server 101 denies access to Salt! 
(Act 505). 

Client computer 108, after obtaining the private key K, may delete the value of 

Saltl. 

With the private key storage system and method described above, even if an 
unauthorized party breaks into one of client computers 108 and steals the wrapped 
version of K and Salt2, it would still be very difficult to derive the private key K. To 
find K, the value of Hashl is necessary, and Hashl can only be computed if the 
user's password PWD, the login name and Saltl are known. Thus without Saltl , K 
cannot be unwrapped. A brute force attack to guess the value of Saltl would be 
infeasible (if Saltl is chosen to be a large enough size, such as 160 bits). If an 
adversary tried to test for the correct password by computing and sending values of 
Hash2 to the server, the server will only allow a limited number of guesses. 
Similarly, if security at key server 101 is compromised and Saltl is accessed, K 
could not be determined without the value of the wrapped K. 

As an alternative to the above-described methods, in which the user is 
authenticated at the remote server based on a password, a biometric device may 
instead be used to authenticate the user. 

It will be apparent to one of ordinary skill in the art that the embodiments as 
described above may be implemented in many different embodiments of software, 
firmware, and hardware in the entities illustrated in the figures. The actual software 
code or specialized control hardware used to implement the present invention is not 
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limiting of the present invention. Thus, the operation and behavior of the 
embodiments were described without specific reference to the specific software code 
or specialized hardware components, it being understood that a person of ordinary 
skill in the art would be able to design software and control hardware to implement 
the embodiments based on the description herein. 

The foregoing description of preferred embodiments of the present invention 
provides illustration and description, but is not intended to be exhaustive or to limit the 
invention to the precise form disclosed. Modifications and variations are possible 
consistent with the above teachings or may be acquired from practice of the invention. 
The scope of the invention is defined by the claims and their equivalents. 
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WHAT IS CLAIMED: 

1 . A method for securing private information comprising: 
calculating a first value and a second value which together are needed to 

derive the private information; 

registering the first value with a remote server; 

securely storing the second value in a local client memory that is independent 
of the remote server; and 

deleting the first value from the local client memory. 

2. The method of claim 1 , wherein the private information is a private key 
in a public/private key pair. 

3. The method of claim 1, additionally including registering an 
authentication value with the remote server. 

4. The method of claim 1 , wherein a password provided by a user of the 
private information is needed to derive the private information in addition to the first 
value and the second value. 

5. The method of claim 4, wherein calculating the first and second values 
includes: 

generating a random value; 

deriving the first value from the random value; and 

deriving the second value from the private information and the random value. 
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6. The method of claim 1 , wherein calculating the first and second values 
includes: 

generating a random value as the first value; 
deriving a wrapping encryption key from the first value; and 
encrypting the private key with the wrapping encryption key to form the 
second value. 

7. A method of securing private information comprising: 
entering a password; 

calculating a first value and a second value and storing the first value and the 
second value in a local client memory, the first and second values together with the 
password being needed to derive the private information; 

calculating an authentication value from the password; 

registering the first value and the authentication value with a remote key 
server; and 

deleting the first value from the local client memory. 

8. The method of claim 7, wherein calculating the first value and the 
second value includes: 

generating a random value; 

generating a first fixed value and a second fixed value; 

deriving the first value from the random value, the password, a user name, 
and the first fixed value; and 

deriving the second value from the private information, the random value, the 
password, the user name, and the second fixed value; 
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9. The method of claim 7, wherein calculating the first value and the 
second value includes: 

generating a random value as the first value; 

deriving a wrapping encryption key from the first value, the password, and a 
user name; and 

encrypting the private key with the wrapping encryption key to form the 
second value. 

10. The method of claim 9, wherein the authentication value is calculated 

by: 

generating a fixed value; and 

deriving the authentication value from the fixed value, the password, and the 
user name. 

11. A method of deriving private information of a user comprising: 
receiving a first value from a key server located remotely from the user, the 

first value being related to the private information; 

retrieving a second value stored on a computer system of the user; and 
calculating the private information based on the first and second values. 

12. The method of claim 1 1 , wherein the calculation of the private 
information additionally includes using a password of the user to calculate the 
private information. 
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13. The method of claim 1 1 , wherein the private information is a private 
key in a public key cryptographic system. 

14. The method of claim 1 1 , further comprising authenticating the user of 
the private information at the remote key server. 

15. The method of claim 14, wherein the method of authenticating is using 
a biometric device. 

16. A method comprising: 

generating a public key and a corresponding private key for a public key 
cryptographic system; 

calculating a first number based on the private key and a random number; 

wrapping the first number using a symmetric encryption key derived from a 
password entered by a user of the private key; and 

registering the wrapped version of the first number with a remote key server. 

17. The method of claim 16, wherein the symmetric encryption key is 
derived from a first hash value based on the password, a user name, and a first fixed 
random number 

18. A computer system comprising: 
a processor; and 

a computer memory connected to the processor, the computer memory 
including a cryptographic program configured to generate a public key and a 
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corresponding private key for a public key cryptographic system, calculate a first 
number based on the private key and a random number, and wrap the first number 
using a symmetric encryption key derived from a password entered by a user of the 
private key; wherein 

the wrapped version of the first number is registered with a remote server and 
then deleted from the computer system, the computer system retrieving the wrapped 
version of the first number before initiating a secure communication session using 
the private key. 

1 9. The computer system of claim 1 8, wherein the computer memory 
calculates the first number by performing a logical exclusive OR of the private key 
and the random number. 

20. The computer system of claim 1 8, wherein the symmetric encryption 
key is derived from a first hash value based on the password, a user name, and a 
first fixed random number. 

21 . The computer system of claim 20, wherein registering the wrapped 
version of the first number with the remote key server further includes: 

transmitting the wrapped version of the first number to the remote key 

server; 

transmitting a user name to the key server; and 

transmitting a second hash value to the key server, the second hash 

value being based on the password, the user name, and a second fixed random 

number. 
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22. A computer readable medium containing instructions for execution by a 
processor, the instructions, when executed: 

generate a public key and a corresponding private key for a public key 
cryptographic system; 

calculate a first number based on the private key and a random number; 

wrap the first number using a symmetric encryption key derived from a 
password entered by a user of the private key; and 

registering the wrapped version of the first number with a remote key server. 

23. The computer readable medium of claim 22, wherein the symmetric 
encryption key is derived from a first hash value based on the password, a user 
name, and a first fixed random number. 

24. The computer readable medium of claim 23, wherein registering the 
wrapped version of the first number with the remote key server further includes: 

transmitting the wrapped version of the first number to the remote key 

server; 

transmitting a user name to the key server; and 

transmitting a second hash value to the key server, the second hash 
value being based on the password, a user name, and a second fixed random 
number. 
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25. A distributed data object stored on a plurality of computers, the 
distributed data object comprising: 

a first component, the first component being wrapped with an encryption key 
based on a hash value that is based on a user password, the first component being 
stored on a key server computer of the plurality of computers; and 

a second component, the second component being wrapped with the 
encryption key and stored on a client computer of the plurality of computers; wherein 

the first and second components of the data object, when unwrapped with the 
encryption key and combined using a logical exclusive OR operation, generate a 
private key in a public/private key encryption pair for a user of the client computer. 

26. The distributed data object of claim 25, wherein the first component is 
calculated from the private key and the second component. 

27. The distributed data object of claim 25, wherein the first component is 
calculated as the logical exclusive OR of the private key and the second component. 

28. The distributed data object of claim 25, wherein the second component 
is a random number. 



20 



ABSTRACT 

To protect a private cryptographic key, two values are derived. The two 
values together can reconstruct the key. One value is sent to a server and deleted 
from the local machine. The other value is held by the local machine. To use the 
key, the user will enter a password, which will be used to authenticate the user to the 
server, and retrieve the value from the server. The password is also used to unlock 
the value held by the local machine. The private cryptographic key is thus protected 
against brute force password attacks without changing the behavior of the user. 
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